In a software development and release environments, detecting and fixing software test failures, (often called “bugs”), as early as possible ensures that the software being integrated or released will be error-free, production-quality software code. In these environments, it can be difficult to determine the root cause of a particular test failure, as well as the change in code that may have introduced the test failure. This problem is exacerbated in larger software development organizations where many individuals and/or teams of individuals are contributing code changes for integration into software builds for testing and product release. In addition, once a test failure has been identified, it is important to determine whether or not the test failure is identical to an existing, known issue or whether the test failure is a new issue that must be assigned to a specific individual or team of individuals who will perform further investigation of the test failure and provide a fix to the code that caused the test failure. Test failure data may include metadata identifying a specific priority, the rate of failure, and/or the configuration of the integration or build environment in which the test failure was discovered.
Stack traces are generated and output by a compiler when the compiler cannot interpret an active stack frame at a certain point in time during the execution of a program. Stack traces may also be displayed to users as part of an error message. Stack traces identify the active stack frames that are associated with the failure. Stack traces are difficult to read and interpret because the format of the stack trace is language-dependent and typically includes a sequenced list of the functions that were called up to the point at which the error occurred and the stack trace was generated. Stack traces can also be retrieved via language specific built-in support, such as system calls, to return the current stack trace. The generated stack traces are commonly used in software development during interactive testing and debugging activities to determine the portions of code that are specifically associated with a particular test failure.
The description provided in the background section should not be assumed to be prior art merely because it is mentioned in or associated with the background section. The background section may include information that describes one or more aspects of the subject technology.